Overall this looks good to me, but I have one strong concern about adding rowHref as a public API in this PR.

The main issue is that the relationship between rowHref and onClickRow is not clear from the API surface. At the call site, they look very similar, but they actually represent different interaction models. rowHref is not just another way to express row navigation, and that difference is not obvious from the prop name, so the API feels surprising.

They are also effectively mutually exclusive, but that is only enforced by a runtime warning and a precedence rule where rowHref wins. I don’t think that is a good public API shape. If two props conflict, that relationship should be explicit in the API rather than encoded in warning behavior.

More broadly, I think row interaction should be expressed through a single API surface rather than split across multiple top-level props. Otherwise users have to learn when to use onClickRow + navigate(...) vs rowHref, even though both are trying to represent row-level navigation.

For this PR, I would prefer to keep onClickRow only and not merge rowHref.

If we later want a first-class row navigation API with explicit modes, I think that should be a separate design discussion or follow-up PR. For example, I could imagine something like:

type RowInteraction<TRow> =
  | { type: "click"; onClick: (row: TRow) => void }
  | { type: "link"; href: (row: TRow) => string; primaryColumnId?: string };

useDataTable({
  columns,
  data,
  rowInteraction: { type: "link", href: (row) => `/orders/${row.id}` },
});

That would make the modes explicit and avoid having both onClickRow and rowHref at the top level.

Thanks @IzumiSy — agree on all points. I've removed rowHref from this PR; it now ships columns-only with the existing onClickRow untouched, so the diff is focused on columns. (rowHref was never released, so no breaking change.)

Row interaction is split into a separate design discussion: tailor-inc/platform-planning#1498, seeded with your rowInteraction discriminated-union proposal. The onClickRow-vs-rowInteraction decision (keep+deprecate vs replace) and the clickable-cells-plus-row-click case (@jason) are captured there as open decisions.

Also noted from Slack: @sean confirmed localStorage is fine for persistence, so that's settled here.

Thanks for the thorough pass @interacsean — pushed fixes in 13ed93d. Rundown by finding:

✅ table-fixed DevX blocker (the big one). Removed the table-wide table-fixed switch entirely. Sticky offsets are now computed from measured header-cell widths (a PinMeasureContext published by DataTable.Table via an isomorphic layout effect + ResizeObserver), so the table keeps its natural table-auto sizing. Pinning no longer requires width — content-sized / inferColumns tables pin correctly and don't collapse. Verified with a width-less column pinned (offsets track the real rendered widths).

✅ Off-by-one drag reorder. Same-zone downward drops now decrement the insert index (fromIdx < index), so it lands where the indicator shows. Cross-zone unaffected.

✅ Width-less pin UI/table mismatch. Resolved by the measure-based change above — a width-less column now genuinely pins in both the popover and the table (no more phantom pin).

✅ Duplicate tableId. Added a dev-mode warning via a mounted-id registry (StrictMode-safe), plus a docs note on uniqueness + the silent in-memory behavior when omitted.

↪️ onClickRow + custom interactive cells. Pre-existing onClickRow behavior, and row-click semantics are being redesigned — deferred to the row-interaction issue tailor-inc/platform-planning#1498 (where the stopPropagation/guard approach will be part of the API).

➖ Positional column-key edge case. Left as-is: it only affects columns with neither id nor label, which already can't reliably persist (we dev-warn for that). The render-side key is now resolved once and threaded, so header measurement + offsets stay consistent regardless.

Also, while testing: balanced the row-actions column padding (kebab was pushed left) and reworked the ColumnSettings drop indicator into a floating line between rows. 🙏

Addressed the Copilot review comments in b60d069:

• usePersistentColumnState — stale layout when tableId cleared: the hydrate effect now resets to defaults when tableId becomes undefined (in-memory mode) instead of keeping the previous table's persisted layout.
• moveColumn — stale order under batching: it now reconciles from prev inside the state updater (shared reconcileColumnOrder helper) rather than a captured columnOrder, so reorders batched before a re-render compose instead of clobbering.

Both are low-severity edge cases (the built-in drag UI uses setColumnOrder, and tableId is typically static) but valid — added regression tests for each.